Generally speaking there is a practical need to provide interoperability among newer updated versions of a wireless protocol and pre-existing equipment operating under the older or legacy version. Wireless infrastructure is not updated all at once, and the SSs that were made and sold prior to the time a legacy specification is updated need to be fully supported while they remain in high numbers within the consumer stream of commerce. The same holds true to a somewhat lesser extent for providing interoperability among wholly different radio protocols (or radio access technologies/RAT), so as to enable a SS with capability for multiple protocols to move seamlessly from one area to another while taking advantage of various different radio technologies that are available in those different areas. WiMAX (worldwide interoperability for microwave access) is one such wireless protocol, and within the WiMAX family is the WirelessMAN (wireless metropolitan area network) specification, which uses an OFDMA (orthogonal frequency division duplex multiple access) scheme. Termed herein as legacy WirelessMAN specification is IEEE 802.16. There is an existing infrastructure of BSs and SSs currently in use that are compliant with legacy WirelessMAN.
Now there is ongoing work to update that legacy standard for WirelessMAN, to be published as the IEEE 802.16m standard which intends to amend the IEEE 802.16 WirelessMAN-OFDMA specification to provide an advanced air interface for operation in licensed bands. Term this the updated WirelessMAN specification. As can be expected, it is also to provide continuing support and interoperability for legacy WirelessMAN-OFDMA equipment, including SSs and BSs. This continuing support is limited to the WirelessMAN-OFDMA Reference System which is defined as system compliant with a subset of the WirelessMAN OFDMA capabilities specified by IEEE 802.16-2004 and amended by IEEE 802.16e-2005 and IEEE 802.16Cor2/D3, where the subset is defined by WiMAX Forum Mobile System Profile, Release 1.0 (Revision 1.4.0: 2007-05-02) [excluding specific frequency ranges specified in the section 4.1.1.2 (Band Class Index)]. Since these are to remain supported and will continue in the updated WirelessMAN specification, the WirelessMAN-OFDMA Reference System is termed herein as legacy 802.16 for simplicity. Further, a BS compliant with a legacy specification (but not the updated specification) is termed herein as a legacy BS; a BS compliant with the updated specification is termed herein as an updated BS; and similar for SSs/MSs/UEs. The specific examples given are in the context of legacy WirelessMAN-OFDMA (IEEE 802.16) and updated WirelessMAN-OFDMA (IEEE 802.16m).
In order to support both legacy SSs and updated SSs in an updated BS, a legacy time zone and an updated time zone have been defined in the frame structure of IEEE 802.16m. The time zone is an integer number (greater than zero) of consecutive subframes. The updated time zone and the legacy time zones are time multiplexed (time division multiplex TDM) across the time domain for the downlink (DL; BS to SS). For uplink (UL; SS to BS) transmissions both TDM and FDM (frequency division multiplex) approaches should be supported for multiplexing of legacy and updated SSs. Both DL and UL traffic for the updated SSs can be scheduled in both zones, whereas the DL and UL traffic for the legacy SSs can only be scheduled in the legacy zones. A prior art depiction of the legacy and updated (new) time zones is shown at FIG. 2, reproduced from FIG. 11.4-5 of C80216m-08—003r1 which describes the super-frame structure of IEEE 802.1 6m as currently agreed. Note that the DL legacy and new zones can be partitioned dynamically on a per-frame basis, and so the split shown at FIG. 2 may differ for the DL.
It may be a requirement of the updated specification IEEE 802.16m that the updated BS support handover of a legacy SS to and from a legacy BS and to and from an updated BS, at a level of performance equivalent to handover between two legacy BSs. There are then seen four different handover scenarios between an updated BS and a legacy BS, detailed below with reference to FIG. 1.                Scenario 1:A legacy SS 7 moves from a legacy BS 8 to an updated BS 9 (SS 7 moving left to right in FIG. 1). The legacy SS 7 will then handover to a legacy time zone of the updated BS 9 and therefore should follow the legacy handover protocol.        Scenario 2:A legacy SS 7 moves from an updated BS 9 to a legacy BS 8 (SS 7 moves right to left in FIG. 1). The legacy SS 7 will then handover from a legacy time zone of the updated BS 9 to the legacy BS 8, and therefore should follow the legacy handover protocol.        Scenario 3:An updated SS moves from a legacy BS 8 to an updated BS 9 (left to right in FIG. 1).        Scenario 4:An updated SS moves from an updated BS 9 to a legacy BS 8 (right to left in FIG. 1).        
The handover (HO) scenarios 3 and 4 above are anticipated to occur typically at the geographical area where the operator has not upgraded all of its legacy BSs in the network. These types of handovers happen during the infrastructure transition period. Generally during such a transition period is desirable to minimize the impact on the deployed/legacy BS and its interfaces to other BSs or other nodes in the network (R4/R6 interface for WirelessMAN). In addition, such HO may also happen between a service provider that provides legacy service but with no intention of upgrading its network (or who has not yet upgraded) and another service provider with an upgraded network.